Various computer system architectures have employed a number of approaches to configuring interactions between devices within a computer system, especially the interaction between an I/O device and core logic within a chipset supporting a processor. Approaches have included the use of firmware (software stored in nonvolatile memory devices) that is executed by a processor to carry out various functions to detect and configure features of a chipset and/or a bus between a chipset and an I/O device. Approaches have also included the provision of device drivers to be executed by a processor as part of executing the code making up an operating system to also detect and/or configure features of a chipset and/or the interaction of those features and a given I/O device.
Various drawbacks arise in these various approaches from the reliance on software, whether within firmware that is executed as a computer system is first powered on or reset, or within device driver software accompanying an operating system. Whenever software is used to detect and/or configure features of any piece of hardware, the selection of software must be paired with and match the selection of hardware, which can be cumbersome and confusing to end users, especially in the case of device drivers, as typical end users of a computer system have very little understanding of what pieces of hardware make up the computer systems they use, let alone what software should accompany those pieces. This dilemma is somewhat ameliorated for end users by the provision of software to detect and/or configure hardware features within the firmware of a computer system, since the firmware is typically matched by the builder of the computer system to the parts making up that computer system. However, once this match has been established between hardware and software, and the software has been stored in the firmware, it can be cumbersome to make changes to that firmware (often more cumbersome than is the case of device drivers) to accommodate the addition of newer pieces of hardware. Often, special utilities are required to “flash” or “burn” a new variant of firmware into nonvolatile storage, and due to the common requirement that such utilities be employed without the benefit of an operating system that could provide various facilities to make the use of a utility easier for end users, this task of changing the firmware can be even more difficult for an end user. The difficulty of dealing with either the flashing/burning of firmware or the changing of operating system device drivers has been addressed, to some degree, by the provision of “option ROM” firmware stored in additional nonvolatile memory devices accompanying new hardware added to a computer system. However, this approach requires this accompaniment of the new hardware by a nonvolatile memory device, and depending on the nature of the hardware added, this may not always be possible.
A further drawback in relying on software, no matter how it is provided, is that a fully initialized processor and memory are required to execute software, and there may be configurations of electronic devices (including computer systems or portions of computer systems) in which a processor and/or memory are unavailable, either altogether, or at least for a period of time following the powering on or resetting of that electronic device. Still, it may be desirable to be able to proceed with detecting and/or configuring hardware features despite the unavailability of either a processor or memory.